Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: expose a JS api through WASM. #17

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

fabricedesre
Copy link
Contributor

No description provided.

Copy link
Member

@cdata cdata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awesome work. Thank you for cutting through the brush and the bramble to figure out if this API is even feasible on the JS side 🙌

For the practical implementation, I think what I would like to see is a newtype that wraps a KeyMaterial and exposes the Promise-ified version of the interface.

This leaves open the question of JS-exposing the rest of the API. KeyMaterial is a good start, but we also need to provide:

And finally, I think packaging for JS should be done in a different project root. Absent a better alternative, I would like to take a page out of Rapier's playbook: a separate project root for a thin, ergonomic JavaScript shim over a WASM-targeted rs-ucan (written in TypeScript). My hope is that JS-specific packaging details can be neatly compartmentalized this way.

Thanks again for enduring all of the papercuts @fabricedesre ❤️

let data = new TextEncoder().encode("Hello World!");
let signature = await keyMaterial.sign(data);
try {
await keyMaterial.verify(data, signature);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

pub fn wasm_get_did(&self) -> WasmResult<Promise> {
let me = self.clone();

Ok(future_to_promise(async move {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💖 future_to_promise

@fabricedesre
Copy link
Contributor Author

This leaves open the question of JS-exposing the rest of the API. KeyMaterial is a good start, but we also need to provide:

* `UcanBuilder`

I started on that one, will post my hack soon. Warning: wasm-bindgen and lifetimes are not the best friends :)

* `DidParser` (keeping in mind implications of #3 & #16)

Ok - that's where I think something like wit (https://github.com/bytecodealliance/wit-bindgen) is better since it makes it easy to import interface implementations from JS. I'll give it a try later.

* `ProofChain`

You scare me.

* Some coherent notion of expressing capabilities; this may just be a POJO/JSON API on the JS side

Right, I'm not sure either how deep in the strongly typed side we need/want to go for that.

  * Capability attenuation will be interesting; right now we depend on the Rust type system to make it work, so we need some generalized way to do the same work without making as rigid an assumption about object shape

Indeed...

And finally, I think packaging for JS should be done in a different project root. Absent a better alternative, I would like to take a page out of Rapier's playbook: a separate project root for a thin, ergonomic JavaScript shim over a WASM-targeted rs-ucan (written in TypeScript). My hope is that JS-specific packaging details can be neatly compartmentalized this way.

I agree - it's weird to hook up the wasm builds to ucan-key-support. But I don't expect much difficulty on that side.

Unfortunately wasm-bindgen can't expose structs with lifetimes,
so this commit removes the lifetime on UcanBuilder. This requires
an additional Clone bound added to KeyMaterial, breaking non-wasm builds.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants